Skip to content

fix(java-enum): resolve enum methods from enum_body_declarations#984

Open
sahil-mangla wants to merge 7 commits into
DeusData:mainfrom
sahil-mangla:fix/java-enum-extraction
Open

fix(java-enum): resolve enum methods from enum_body_declarations#984
sahil-mangla wants to merge 7 commits into
DeusData:mainfrom
sahil-mangla:fix/java-enum-extraction

Conversation

@sahil-mangla

Copy link
Copy Markdown
Contributor

What does this PR do?

Resolves extraction and calling-edge issues for Java enums that define methods (e.g., isWeekend or label in cp_enum_method_java).

In tree-sitter-java, an enum's methods are declared within an enum_body_declarations block, which is a nested child of enum_body rather than a direct child of the enum declaration itself. Previously:

  • find_class_body resolved only the raw enum_body node.
  • extract_class_methods iterated over this body, encountering constants and separator tokens, but missing the nested enum_body_declarations block. As a result, method definitions were ignored and calling edges failed to resolve.

This change:

  1. Updates find_class_body to correctly scan and inspect the enum_body for nested enum_body_declarations nodes and return them.
  2. Adds enum_body and enum_body_declarations to the list of recognized body containers in push_class_body_children so the AST traverser pushes all method declarations under the correct enum QN namespace.
  3. Complies with the 100-character column format limit in extract_defs.c.

Checklist

  • Every commit is signed off (git commit -s) — required, CI rejects unsigned commits (DCO, see CONTRIBUTING.md)
  • Tests pass locally (make -f Makefile.cbm test)
  • Lint passes (make -f Makefile.cbm lint-ci)
  • New behavior is covered by a test (reproduce-first for bug fixes)

Java enums with methods (e.g. isWeekend/label in cp_enum_method_java)
have their method declarations inside enum_body_declarations, which is a
child of enum_body — not a direct child of enum_body itself.

find_class_body was returning the raw enum_body node (16 children:
enum_constant×7, commas, and the nested enum_body_declarations). As a
result, extract_class_methods iterated enum_constant/comma nodes and
never visited any method_declaration, so no Method nodes were created
and no CALLS edges resolved.

Fixes:
- find_class_body: if a body resolved via field-name lookup is enum_body,
  look for enum_body_declarations inside it and return that instead.
- find_class_body fallback loop: same unwrapping for the type-scan path.
- push_class_body_children: add enum_body and enum_body_declarations to
  the recognised body-container kinds so the walk_defs stack correctly
  scopes enum method children under the enum QN.

Tests: convergence_probe 47/47 passed (was 46/47, cp_enum_method_java
was the failing case).

Signed-off-by: sahil-mangla <manglasahil2017@gmail.com>
Wrap two if-conditions that exceeded the 100-column limit:

- Line 3506: break &&-condition before the parenthesised ObjC/Java
  language check so the line stays within 100 cols.
- Lines 5860-5861: split the combined enum_body / enum_body_declarations
  comparison onto separate continuation lines to satisfy the limit.

No logic change; formatting only.

Signed-off-by: sahil-mangla <manglasahil2017@gmail.com>
@sahil-mangla sahil-mangla requested a review from DeusData as a code owner July 9, 2026 17:41
@DeusData DeusData added this to the 0.9.1-rc milestone Jul 9, 2026
@DeusData DeusData added bug Something isn't working parsing/quality Graph extraction bugs, false positives, missing edges priority/normal Standard review queue; useful PR with ordinary maintainer urgency. labels Jul 9, 2026
@DeusData

DeusData commented Jul 9, 2026

Copy link
Copy Markdown
Owner

Thanks. I have triaged this as a 0.9.1-rc Java extraction bug fix. Review should verify that enum_body_declarations handling fixes enum methods without changing normal class/interface method extraction or introducing duplicate method definitions.

@DeusData

DeusData commented Jul 9, 2026

Copy link
Copy Markdown
Owner

Thanks for splitting this out of #893 so quickly — exactly the atomic shape we asked for, and the enum_body_declarations analysis matches tree-sitter-java's grammar. One thing missing before merge: a genuine reproduce-first guard. I ran the existing cp_enum_method_java convergence probe on unmodified main and it already PASSES — its assertions (Enum node exists + ≥1 CALLS edge anywhere) are too loose to detect the bug you're fixing, so nothing in CI currently turns red without your change. Please add an extraction-level test that is RED on main and GREEN with this fix — e.g. in tests/test_extraction.c, extract the Day enum fixture and assert isWeekend/label exist as Method definitions (and/or tighten the probe to assert the enum's methods specifically). With that guard in place this merges immediately.

Signed-off-by: sahil-mangla <manglasahil2017@gmail.com>
… receivers

Limit same-module suffix fallback in resolve_same_module to only fire if the receiver is a self-receiver or matches the module/namespace. Also reject matching dotted/colon-qualified callees targeting a Function to a different prefix in name lookup. This prevents false-positive recursion flags on store/delegation calls.

Signed-off-by: sahil-mangla <manglasahil2017@gmail.com>
Signed-off-by: sahil-mangla <manglasahil2017@gmail.com>
@DeusData

Copy link
Copy Markdown
Owner

Thanks for this, @sahil-mangla — the Java enum-method extraction fix is genuinely good work, and the java_enum_method test is a proper reproduce-first guard (it fails on main without the enum_body_declarations unwrap). I'd happily merge that part quickly.

One blocker before it can land: the PR also carries an undocumented change to the call-resolution coresrc/pipeline/registry.c (+127/−22), restricting resolve_same_module/resolve_name_lookup on receivers (commits e930bd2 + 078de1c). That's a precision-tightening change to CALLS-edge resolution with all-language blast radius, and it's not mentioned in the PR description. Per our atomic-PR policy it needs to be its own PR so its recall-vs-precision impact can be evaluated on the full corpus independently of the enum fix.

Could you split this into two PRs?

  1. The Java enum fixextract_defs.c (enum_body/enum_body_declarations unwrap + enum-name fallback) + tests/test_extraction.c. This is clean and I'll fast-track it.
  2. The registry resolution-tighteningregistry.c + tests/test_registry.c, with a note on what false positive it targets (looks recursion-related) so we can measure edge impact before merging.

Really appreciate the contribution — just want each change reviewable on its own merits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working parsing/quality Graph extraction bugs, false positives, missing edges priority/normal Standard review queue; useful PR with ordinary maintainer urgency.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants